RenPar'18 / SympA'2008 / CFSE'6 
Fribourg, 11 au 13 février 2008 



oo 

o 



Étude de performance des systèmes de découverte de ressources 

Heithem Abbes^'^ Christophe Cérin^ Jean-Christophe Dubacq^ Mohamed Jemni^ 
-'^ École supérieure des sciences et techniques de Tunis, Unité de recherche UTIC 
5, Av. Taha Hussein, B.P. 56, Bab Mnara, Tunis, Tunisia 
Tel : (+216) 71 496 066 Fax : (+216) 71 391 166 
heithem. abbesSesstt . rnu. tn mohamed. jemniOf st . rnu. tn 

2LIPN, UMR 7030, CNRS, Université Paris-Nord 
99, avenue Jean-Baptiste Clément, 93430 Villetaneuse, France 
Tel : +33-(0)1.49.40.35.78 Fax : +33-(0)1.48. 26. 07.12 
' {Christophe . cerin, jestn-christophe . dubacq}(§lipn .univ-parisl3 . f r 

(N ■ 

<^ 

^ ■ Résumé 

I Les grilles de PC (Desktop Grid) sont une technologie qui consiste à exploiter des ressources géographi- 
■ quement dispersées, pour traiter des applications complexes demandant une grande puissance de calcul 
et une capacité de stockage importante. Cependant, comme le nombre de ressources augmente, les be- 
' soins de changement d'échelle, d'auto-organisation, de reconfiguration dynamique, de décentralisation et 
I de performance deviennent de plus en plus indispensables. Comme ces propriétés sont présentes dans 
les systèmes P2P (pair-à-pair), la convergence des grilles et des systèmes P2P semble naturelle. Dans 
Q I ce contexte, l'article évalue l'adaptation au changement d'échelle et la performance des outils P2P pour 
la publication/découverte de services. Trois bibliothèques sont évaluées à cet effet : Bonjour, Avahi et 
Pastry. Nous étudions leur comportement vis à vis des critères qui sont le temps écoulé pour l'enregistre- 
^ ■ ment des services et le temps nécessaire pour en découvrir de nouveaux. Notre objectif est d'analyser ces 
I résultats afin de choisir le meilleur protocole que nous pourrons utiliser à terme afin de créer un intergiciel 
0^ ■ décentralisé pour les Desktop Grid. 

m ■ 

■"nJ" I Mots-clés : Desktop Grid, Évaluation de performance. Découverte de services, ZeroConf, Pastry. 
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Les grilles de calcul répondent aux différents besoins de calcul avec un coût économique. Une variante 
est la grille de PC (Desktop Grid) où les nœuds sont simplement constitués de PC de bureau. Cette 
variante constitue notre cadre de travail. La majorité des intergiciels pour les grilles de PC actuels sont 
centralisés. Dans ce contexte, notre travail consiste à concevoir un intergiciel de Desktop Grid de calcul 
décentralisé et basé sur les systèmes P2P. Pour réaliser cela, nous voudrions profiter des systèmes P2P 
décentralisés existants. Dans ce travail, nous supposons que nous disposons d'un intergiciel de haut niveau 
capable à virtualiser le réseau (nous n'avons plus de problèmes avec les pare-feu et NAT) et nous pouvons 
exécuter Bonjour, Avahi et Pastry au dessus de cet intergiciel (Bonjour, Avahi et Pastry fonctionnent sur 
un réseau local). Instant Grid / Private Virtual Cluster [4] est l'un des candidats pour la virtualisation 
des réseaux. Ses principales exigences sont : 1) une configuration simple du réseau 2) pas de dégradation 
de la sécurité d'une ressource 3) pas de besoin de réimplémenter des applications distribuées existantes. 
Sous ces hypothèses, il est raisonnable de s'intéresser aux performances de Bonjour, Avahi et Pastry. 
La découverte de services dans la grille est parmi les principaux défis à relever. Par exemple, l'intergiciel 
Globus met en œuvre le service publication/découverte, un mécanisme fondé sur le contrôle et la décou- 
verte de Services (MDS-2) [2]. Ce protocole utilise un serveur d'enregistrement centralisé. MDS-2 est 
en fait une architecture hiérarchique, mais il est encore très vulnérable avec un seul point de défaillance. 
En outre, l'adaptation à la dynamicité de serveurs est un autre défi pour MDS-2. Une autre alternative 
consiste à utiliser une approche décentralisée pour la découverte de services [8]. Récemment, la com- 
munauté P2P a élaboré un certain nombre de protocoles totalement décentralisés, tels que Bonjour [6], 
Avahi [TT] et Pastry [H [12] pour l'enregistrement, le routage et la découverte dans les réseaux P2P. 



L'idée de base derrière ces protocoles est d'établir l'auto-organisation et la configuration dynamique des 
organisations virtuelles lorsque de nouveaux nœuds rejoignent ces organisations. 

L'article est organisé comme suit : dans le paragraphe 2 nous présentons la notion de grilles de PC et 
nous illustrons les avantages des systèmes P2P pour construire de telles grilles. Par la suite, dans le 
paragraphe 3, nous décrivons la procédure des tests d'expérimentation pour analyser la performance de 
Bonjour, Avahi et Pastry. Dans les paragraphes 4, 5 et 6, nous discutons les résultats numériques que 
nous avons obtenus après plusieurs expérimentations faites sur la plate-forme Grid'5000 (jusqu'à 308 
machines). Une conclusion et des perspectives clôturent l'article. 



2. Les grilles de PC (Desktop Grid) 

Les grilles de calcul (comme Grid'5000) visent à fournir une infrastructure avec une qualité de service 
garantie entre des ressources (relativement) homogènes et des communautés certifiées. En revanche, les 
systèmes P2P se concentrent sur la construction d'une très grande infrastructure entre grandes commu- 
nautés non certifiées, entre individus anonymes et entre ressources volatiles. Toutefois, la convergence des 
deux systèmes semble naturelle [1 . En fait, les travaux de recherche sur les systèmes P2P cherchent de 
plus en plus à fournir des infrastructures capables de supporter des applications diversifiées alors que la 
recherche en grille commence à se soucier de la massification et de l'extensibilité. 

Sous l'hypothèse d'un réseau virtuahsé [4], le choix de Avahi et Bonjour est justifié par le fait qu'ils 
sont deux implémentations du protocole ZeroConf (Zéro Configuration Networking) qui a déjà prouvé sa 
fiabilité dans le domaine des réseaux locaux et qui peut être extensible sur les réseaux WAN (en utilisant 
l'envoi Unicast et le DNS). Parmi les protocoles basés sur une DHT (Distributed Hash Table) tels que 
CAN [3] et CHORD j7j, nous avons choisi Pastry car, d'une part, il offre les possibilités de réplications 
et de DHT et, d'autre part, il existe une implémcntation open-source directement exploitable |12] . 

2.1. Bonjour 

Bonjour est une implémcntation par Apple du protocole ZeroConf. Le but est d'obtenir un réseau IP 
fonctionnel sans dépendance d'une infrastructure comportant un serveur DHCP et un serveur DNS ou 
d'une expertise réseau. Bonjour est architecturé autour de trois fonctionnalités : il permet l'allocation 
dynamique d'adresses IP sans serveur DHCP, il assure la résolution de noms et adresses IP sans serveur 
DNS et effectue la recherche des services sans annuaire. Au niveau technique. Bonjour utilise les adresses 
de lien-local. Lorsque le serveur DHCP échoue ou n'est pas disponible, le lien-local permet à un ordinateur 
d'obtenir une adresse IP (de type IPv4) tout seul. En IPv4, l'adresse de lien-local est sélectionnée au moyen 
d'un générateur pseudo-aléatoire dans la plage d'adresses de 169.254.1.0 à 169.254.254.255 incluses. La 
vérification d'unicité d'adresse de lien-local fonctionne à partir de trois requêtes ARP probes qui sont 
diffusées sur le lien local. Si l'adresse IP est déjà utilisée (ou demandée) par une autre machine, alors on 
tente une autre adresse fournie par le générateur. Lorsque la machine trouve une adresse libre, elle diffuse 
en broadcast deux annonces ARP avec l'adresse source IP contenant l'adresse sélectionnée. En fait, si à 
un moment quelconque on obtient une adresse par DHCP alors on utilise cette adresse et on abandonne 
le processus d'auto-configuration sur le lien local. Comme les adresses de lien-local, lorsque les serveurs 
DNS ne sont pas disponibles ou inaccessibles, les machines peuvent encore se référer les uns aux autres 
par nom en utilisant le protocole mDNS (Multicast DNS). Bonjour utilise le protocole DNS-SD (DNS 
Service Discovery) pour découvrir les services publiés dans un réseau local. Puisque DNS-SD est construit 
au dessus de DNS (ce sont des requêtes avec le champs TXT qui sont utilisées), il travaille non seulement 
avec les mDNS, mais aussi avec les DNS classiques pour la découverte de services à distance. 

2.2. Avahi 

Avahi est un système qui facilite la découverte de services sur un réseau local. Il permet à des programmes 
de publier et de découvrir les services et les hôtes fonctionnant sur un réseau local sans aucune configura- 
tion spécifique. Avahi est une mise en œuvre des spécifications DNS-SD et Multicast DNS de ZeroConf. 
Avahi est essentiellement basé sur l'implémentation Linux de mDNS. Il utilise D-Bus (une bibliothèque 
de communication asynchrone entre processus) pour la communication entre applications. 



2 



2.3. Pastry 

Pastry permet de construire un réseau P2P fondé sur les clés de hash distribuées, il réalise une correspon- 
dance entre un identifiant et une valeur de hash [Sj. Cette correspondance permet de placer directement 
une ressource dans le réseau de pairs. Pastry est une infrastructure générique, évolutive et efficace pour 
les applications P2P. Les noeuds de Pastry forment un réseau de pairs (ou anneau logique) décentralisé, 
auto-organisé et tolérant à la panne. Ceci le différencie des précédents protocoles étudiés. La construction 
de l'anneau Pastry commence par la création du nœud bootstrap. Par la suite, tous les nouveaux arri- 
vés contactent le noeud bootsrap pour rejoindre l'anneau logique. Chaque nœud a un identifiant unique 
(nodeld) et une table de routage et un leaf set qui contient les nodeld des nœuds voisins. Lorsqu'il est 
présenté avec un message et une clé, un nœud Pastry route efficacement le message au nœud qui a le 
nodeld le plus proche numériquement de la clé, à travers tous les nœuds couramment vivants. Pastry est 
complètement décentralisé, évolutif, auto-organisé et auto-déterministe ; il s'adapte automatiquement à 
l'arrivée, le départ ou l'échec de connexion de nœuds. Pastry tient compte de la localité dans le réseau ; 
il vise à réduire le temps de transfert des messages, en minimisant le nombre de sauts de routage IP. 

3. Description de la phase expérimentale 

La plate-forme expérimentale utilisée est Grid'5000 [13], hautement reconfigurable et contrôlable, qui 
rassemble 9 sites géographiquement distribués en France. Tous les sites sont connectés par le réseau 
RENATER (10 Gb/s). Nos tests sont appliqués sur le site d'orsay, oii les nœuds sont connectées par un 
réseau de 1 Gb/s. Nous avons utilisé presque la totalité des machines disponibles dans ce site (plus de 
300 machines). Toutes les machines ont des processeurs AMD Opterons et des cartes réseaux 1 Gb/s. 
Nous représentons les nœuds par des services pour construire un réseau virtuelle sur la palteforme 
Grid'5000. En effet sur chaque machine nous enregistrons un service, ainsi, si le service fonctionne alors 
la machine est connectée sur le reseau, sinon (nous désactivons ou nous supprimons le service) la machine 
est déconnectée. 

Notre objectif est d'étudier la capacité de massification et le temps de réponse des systèmes P2P décrits 
plus haut. En fait, nous cherchons le nombre maximal de nœuds qui peut être supporté par ces outils et 
le temps de réponse nécessaire pour découvrir un nouveau nœud qui vient de se connecter sur le réseau 
(selon l'état de la grille). Les mêmes critères de mesures sont appliqués pour les trois systèmes. 

3.1. Construction d'un noyau spécifique pour Grid'5000 

Grid'5000 offre une infrastructure avec des noyaux standards. Pour exécuter nos tests expérimentaux, 
nous avons personnalisé un noyau pour supporter Avahi, Bonjour et Free-Pastry. Ainsi, nous avons créé 
un noyau spécifique contenant tous les packages nécessaires à l'exécution de nos codes. Par la suite, en 
utilisant les deux outils OAR fT^ et Kadeploy nous réservons et nous déployons le noyau spécifique 
sur toutes les machines réservées selon la procédure maintenant classique pour les utilisateurs. 

3.2. Enregistrements séquentiels 

Dans ce test, la première étape est de réserver N nœuds sur Grid'5000 (N varie de 100 nœuds jusqu'à 
atteindre la valeur de saturation pour l'enregistrement de services) . Le nombre N représente le maximum 
de nœuds qui peut être utilisé pour l'expérimentation. Chaque nœud demande une inscription pour un 
service donnée à un instant t. Initialement, tous les nœuds ont le code adéquat pour enregistrer un 
service qui reste inactif tant que la demande n'est pas encore activée. Soit ô le temps d'activation de la 
demande. Nous activons séquentiellement (chaque ô seconds) toutes les demandes (et nous recevons un 
accusé de notification). Ainsi, la k^demande sera exécutée à la fc x (5 unité de temps. Nous augmentons 
S pour analyser le comportement du système lorsque le délai entre les événements devient plus grand. 
Evidemment, au début, le nombre d'enregistrements est petit, ainsi le temps d'enregistrement est minime. 
Nous cherchons à analyser la massification des systèmes sans saturer le réseau : dans ce type de tests, 
seulement un envoi multicast apparaît dans un temps donné. 

3.3. Enregistrements simultanés 

Dans le premier test, les enregistrements sont exécutés d'une manière séquentielle, à un instant t chaque 
nœud envoie un seul message, par conséquent le nombre de communication est limité. Dans ce type d'ex- 
périmentations, nous « stressons » la scalabilté du système et sa capacité à gérer les communications 
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entre les nœuds enregistrés. Par conséquent, nous demandons N (nombre des nœuds réservés) enregistre- 
ments simultanés et nous mesurons le temps nécessaire pour terminer la phase d'enregistrement. Si nous 
obtenos un temps de réponse raisonnable, nous augmentons la valeur de N jusqu'à arriver à une valeur 
de saturation. Autrement, nous cherchons le nombre maximum de nœuds qui peut être enregistré lorsque 
plusieurs communications (de type multicast) sont présentes sur le réseau. 

3.4. Découverte de services 

Pour évaluer les trois systèmes candidats, nous avons aussi pris comme métrique d'évaluation le temps de 
découverte d'un service. En effet, le temps de découverte est le temps écoulé entre la fin d'enregistrement 
d'un service et sa découverte par le programme browser qui tourne sur une seule machine. Notons que 
le temps de réponse dépend du nombre de nœuds enregistrés. Le programme browser écoute n'importe 
quel nouvel événement, i.e. un nouvel enregistrement ou la suppression d'un service. 
Avec les deux types d'enregistrements mentionnés ci-dessus, nous pouvons analyser l'efficacité de la 
découverte des services pour les trois systèmes candidats. 



4. Performances de l'enregistrement des services 
4.1. Enregistrement des services de Bonjour 




FiG. 1 - Temps écoulé pour l'enregistrement simultané des services de Bonjour 




FiG. 2 - Temps écoulé (triés dans l'ordre croissant) pour l'enregistrement simultané des services de 
Bonjour 



Bonjour commence par faire une requête DHCP pour obtenir une adresse. En cas d'absence du DHCP, il 
effectue une (jusqu'à 3) requête(s) ARP ; or quand on démarre le noyau, une IP est déjà attribuée, donc 
on ne peut pas tenir compte du temps écoulé dans cette première phase. Bonjour fait, ensuite, en sorte 
d'informer toutes les machines que le nœud a le service en question, il s'agit donc de mettre à jour les 
caches ARP. Il pourrait y avoir un coût de gestion supplémentaire lié à des remplacements dans le cache 
mais la taille par défaut des caches ARP est 1040 entrées ce qui est supérieur au nombre de services 
que l'on déclenche dans le pire cas de nos expériences. On ne peut pas raisonnablement incriminer la 
gestion des caches ARP dans la dégradation des performances. Bonjour continue par une vérification que 
le service est unique. Une première annonce ARP est faite avec une attente d'une seconde {Probe wait = 
Is). S'il n'y a pas eu de réponse dans la seconde (c'est bien le cas, car tous les services ont été choisis 
avec un nom unique), alors le nom est considéré comme unique. 
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La figure [T] illustre les temps d'enregistrement simultané. Jusqu'à 308 machines, le temps écoulé pour 
l'enregistrement varie entre 1017 ms et 2307 ms. Sur cette figure l'axe des abscisses donne le numéro de 
service et l'axe des ordonnées sont les temps (chaque machine i enregistre le service i). Il se peut que le 
service k s'enregistre avant le service k-p (k et p > 0) ce qui explique l'aspect « bruit de fond » de la 
figure [TJ 

L'enregistrement séquentiel (la figure n'est pas donnée faute de place), montre une réduction des temps 
d'enregistrement des services. En effet, les mesures effectuées sur 308 machines donnent des temps d'en- 
registrement compris entre 1015 et 1030 ms (presque stable). Pour mieux analyser le comportement de 
l'enregistrement simultané de services, nous avons tracé la courbe de la figure [5] en triant dans l'ordre 
croissant les temps d'enregistrement simultané. En effet, comme nous l'avons mentionné, dans le test 
séquentiel le coût varie entre 1015 ms et 1030 ms, dans le cas simultané, on retrouve cette constante mais 
il faut en plus accéder au bus à tour de rôle et cela coûte de l'ordre de 10 à 30 ms, ce qui engendre une 
augmentation cumulé du temps d'enregistrement de 1017 ms à 2307 ms. 

4.2. Enregistrement des services de Avahi 




FiG. 3 - Temps écoulé pour l'enregistrement simultané des services de Avahi 




FiG. 4 - Temps écoulé pour l'enregistrement séquentiel des services de Avahi 



Sur chaque nœud du réseau Avahi, il y'a un démon avahi-daemon qui tourne. Ce démon implémente les 
deux protocoles mDNS/DNS-SD de Zeroconf. L'enregistrement d'un service revient à publier un service 
avec un envoi multicast à tous les nœuds en utlisant D-Bus comme protocole de transport et mettre à 
jour les caches de chaque nœud. Ces protocoles ont montré une grande efficacité dans l'enregistrement des 
services. En effet, les figures [3]et Ulmontrent que Avahi donne presque les mêmes temps d'enregistrements 
dans les tests séquentiels et simultanés. Le temps écoulé varie entre 760 et 1110 ms. En comparaison avec 
Bonjour, Avahi donne de meilleurs temps d'enregistrements. 

4.3. Enregistrement des services de Pastry 

Contrairement à Avahi et Bonjour, Pastry montre une grande différence entre les tests d'enregistrements 
séquentiels et simultanés. En effet, la figure O montre que dans l'enregistrement simultané, jusqu'au 
IGO^^service, le temps écoulé varie entre 600 et 1000 ms. Au delà, le temps d'enregistrement augmente d'un 
enregistrement à un autre pour atteindre 320 000 ms. D'autre part, la figure |4] montre que l'enregistrement 
séquentiel donne de meilleurs temps d'enregistrement. Nous remarquons que Pastry donne des temps 
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FiG. 5 - Temps écoulé pour l'enregistrement simultané des services de Pastry 
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FiG. 6 - Temps écoulé pour l'enregistrement séquentiel des services de Pastry 

d'enregistrement réduits par rapport à Avahi et Bonjour ( 30% des services, parmi 307, sont enregistrés 
dans l'intervalle de 450 à 550ms). En effet, lorsque nous enregistrons un service, nous exigeons la connexion 
à la machine bootstrap (pour ne pas créer plusieurs anneaux). Ainsi dans l'enregistrement simultané, la 
machine bootstrap ne peut pas répondre à toutes les requêtes simultanées, d'oii la croissance très rapide 
des temps d'enregistrement depuis le service n° 160. En plus Pastry met à jour les leaf sets pour maintenir 
la cohérence du système, et c'est peut être aussi pour cette raison que dans la version simultanée les temps 
d'enregistrement arrivent à 320 s. Alors que dans la version séquentielle, la machine bootstrap ne reçoit 
qu'une seule requête chaque minute ; la mise à jour des leaf sets et des tables de routage est ainsi recouvrée 
d'oii des temps d'enregistrement minimes (2s au maximum). 

5. Performances de la découverte de services 

La deuxième métrique consiste à mesurer le temps nécessaire à la découverte d'un service enregistré. 
Ainsi, pour chaque système (Bonjour, Avahi and Pastry), nous mesurons le temps écoulé entre la fin de 
l'enregistrement et l'instant de découverte. Nous reprenons les mêmes mesures pour les deux types d'enre- 
gistrements simultané et séquentiel. Pour cela, nous consacrons une machine pour exécuter le programme 
d'écoute (ou Browser) pour la découverte de services. 

5.1. Comportement de la découverte de Bonjour 

Bonjour prouve une haute performance en découverte de services. En effet, il est capable de découvrir, 
dans les deux versions (séquentielles et simultanées), 307 services enregistrés sur 307 machines (un ser- 
vice par machine). Le temps de découverte ne dépasse pas 1 seconde. Cela nous conduit à affirmer que 
l'implementation par Apple de DNS-SD fonctionne très bien et donne des résultats satisfaisants. 

5.2. Comportement de la découverte de Avahi 

Comme nous l'avons déjà mentionné, Avahi utilise le démon avahi-daemon et fait une requête via D-Bus 
pour publier un service par un paquet multicast. La machine qui lance le programme de découverte (un 
programme Browser qui reste à l'écoute des services), perd 60% des services enregistrés d'une manière 
simultanée. En plus, le temps de découverte augmente au delà de 49 enregistrements pour atteindre 900 s 
dans l'enregistrement du 73''service. Au delà, le programme de découverte d'Avahi passe autour de 220 s 
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FiG. 7 - Temps de découverte pour l'enregistrement simultané des services de Avahi 

pour découvrir un service enregistré (voir figure [7]). Contrairement à l'enregistrement simultané, lorsque 
nous enregistrons les services d'une manière séquentielle (chaque minute, nous enregistrons un service), 
le programme Browser est capable de découvrir plus de services (303 parmi 307 services enregistrés) . En 
plus, le temps de découverte est meilleur (4 s au maximum) pour 204 services sauf que pour 9 services 
demandent des temps de l'intervalle 2835-8686 s. 

La machine de découverte (browser) , qui a le démon avahi-daemon en exécution, n'arrive pas à recevoir, 
à un instant donné, tous les envois multicasts émis par les nœuds qui ont enregistré les services au même 
instant (cas simultané), ce qui peut expliquer la perte des services dans la version simultanée. Alors que 
dans la version séquentielle, le browser nécessite plus de temps (> 8686s ~ 2.5 heures) pour la découverte 
des quatre services perdus. 

5.3. Comportement de la découverte de Pastry 

Dans les deux types d'enregistrements séquentiel et simultané, pastry donne des temps de réponse rapide 
de découverte (au plus en Is). Quant au nombre de services découverts, pour l'enregistrement simultané, le 
browser découvre 270 parmi 293 services, alors que pour l'enregistrement séquentiel, le browser découvre 
275 des 292 services ce qui correspond à une légère amélioration vis à vis du cas précédent. Cela peut nous 
conduis à affirmer que la machine Browser n'arrive pas à récupérer tous les annonces de publications des 
services si nous dépassons environ 270 enregistrements. 

6. Synthèse 

La comparaison des trois bibliothèques Bonjour, Avahi et Pastry du point de vue des temps d'enregis- 
trements simultanés d'environ 300 services sur la plate-forme Grid'5000 (un service par machine) montre 
que Avahi est le meilleur puisqu'il met le moins de temps (le dernier service enregistré demande 1000 ms). 
Bonjour nécessite 1300ms de plus pour enregistrer le dernier service. Pastry donne des temps proches de 
ceux mis par Avahi jusqu'à l'enregistrement de 150 services, mais au delà il met des temps nettement 
plus grands (jusqu'à 32000ms) que ceux de Avahi et Bonjour. 

Quand nous enregistrons séquentiellement un service sur chaque machine (nous arrivons jusqu'aux en- 
virons de 300 machines), nous pouvons mentionner qu'il n'y a pas une grande différence entre les trois 
bibliothèques. En fait. Bonjour et Avahi donnent des résultats semblables. Pastry met presque le même 
temps pour enregistrer 60% des services, a besoin de moins de temps pour enregistrer les premiers 30% 
mais de plus de temps que Avahi et Bonjour pour les 10% qui restent. 

7. Conclusion 

Avec la croissance de la taille des grilles, il est très envisageable d'utiliser les systèmes P2P reconnus pour 
leur capacité de massification et leur gestion de la volatilité. A ce propos, nous avons étudié dans cet 
article trois protocoles P2P pour la découverte de ressources qui sont Bonjour, Avahi et Pastry. Les trois 
protocoles ont montré de hautes performances sauf qu'Avahi n'a pas réussi à découvrir tous les services 
dans la version simultanée et que Pastry met un temps considérablement long pour enregistrer tous les 
services dans la version simultanée. Nous continuerons à travailler à terme avec les trois protocoles. En 
effet, Bonjour est très performant dans l'enregistrement et la découverte dans les deux versions séquentielle 
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et simultanée. Pastry a aussi prouvé sa performance dans l'enregistrement séquentiel et aussi dans la 
version simultanée pourvu qu'on ne dépasse pas les 160 services à un instant donné ce qui ne représente 
pas vraiment un point de faiblesse si on ne travaille pas avec 10 millions de nœuds. En fait, comme nous 
l'avons déjà mentionné, étant donné que le grand nombre de connexions à la même machine bootstrap 
est à l'origine de ce problème, nous pouvons y remédier par la création d'un deuxième bootstrap pour 
initialiser un deuxième anneau logique. Avahi présente l'avantage d'être libre avec le code source accessible, 
ce qui rend son étude beaucoup plus facile que Bonjour. Du point de vue technique, l'API de ZeroConf 
n'offre pas toutes les fonctionnalités pour construire un intergiciel de grille, alors que Pastry offre une 
API open source développée avec Java contenant les fonctions préliminaires nécessaires à l'élaboration de 
cet intergiciel. Notre objectif final est de construire un intergiciel de Desktop Grid basé sur l'un de ces 
protocoles. 
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